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COMPUTER DIRECTORY SYSTEM HAVING AN 
APPLICATION INTEGRATION DRIVER INFRASTRUCTURE 



Background Section 

This invention relates generally to computer software, and more specifically to 
a system and method for allowing an application program to integrate and/or 
synchronize with a computer directory by providing a driver infrastructure for virtual 
replicas and the like. 

Personal computers or workstations may be linked in a computer network to 
facilitate the sharing of data, applications, files, and other resources. One common 
type of computer network is a client/server network, where some computers act as 
servers and others as clients. In a client/server network, the sharing of resources is 
accomplished through the use of one or more servers. Each server includes a 
processing unit that is dedicated to managing centralized resources and to sharing 
these resources with other servers and/or various personal computers and 
workstations, which are known as the "clients" of the server. 

Directories and directory services are often provided to enable a digital 
environment for a particular resource. One example of a directory service is Novell 
Directory Services ("NDS") for Novell Netware networks, as provided by Novell, Inc. 
of Provo, Utah. NDS provides a logical tree-structure view of all resources on the 
network so that clients can access them without knowing where they are physically 
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located. For a given resource, an entry is made in a directory such as NDS. Specific 
entries of a directory are only available by directly accessing the directory. 

Typically, a directory is established for one or more applications to access. A 
directory will have, for example, a native application program interface ("API") that 
5 provides a set of routines, protocols, and tools for using the directory. In this way, 
the directory's native API allows programmers to write applications that can utilize 
the information stored in a directory with appropriate access control. As a result, the 
applications must conform to the directory. 

There has only been marginal success in the arena of application integration 
10 with directories. One of the primary problems is that many applications have already 

been written that utilize the same resources that are defined and managed from a 
Jj directory. Also, many application programs were created prior to the advent of wide 
+; spread directory use. Of course any changes to application programs are inherently 
□ delicate, and are therefore undesirable. 

jj5 Since these software applications cannot (or will not) access an entry as it 

* * resides in a particular directory, the applications will instead store information about 
^ the resource in their own directory-like data store. This creates a partial duplicate of 
H| ^e information which the application can access. Furthermore, the application can 
; •{ potentially augment the duplicated information. As a result, a given resource may be 
&0 fractured among a number of applications or data repositories. As the number of 
applications that utilize a given resource increases, the likelihood of information 
about a given resource being unsynchronized, and therefore invalid, increases. 

Replication is often used to synchronize distributed data within a given 
application in an automated and unattended manner. Replication enables many 
25 computers or computer applications to work with their own local, current copy, or 
replica, of a resource entry. For database applications where computers are widely 
distributed (e.g., geographically), replication provides an efficient way for distributed 
systems to access current information. To alleviate problems caused by partial data 
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duplication, applications often try to maintain the validity of the replica by 
communicating with other applications that share the data stored in the replica. 
However, it is still important for the application to directly access the directory using 
the directory's native API or online directory service protocols like LDAP, or 
Lightweight Directory Access Protocol. 

It is desired to provide centralized management of distributed resources to 
applications that utilize those resources, without requiring the applications to be 
rewritten to utilize the directory directly. 

It is also desired to provide a directory interface that does not require updates 
or changes to an application program. 

It is further desired to have a directory maintained as if multiple applications 
were working on a single, centralized directory. 

Summary 

In response to these and other problems, an improved system, method and 
software program is provided for facilitating the use of components running in a 
computer network. To this end, the improvement provides a driver infrastructure 
between components such as a distributed directory and a computer application. 
The driver infrastructure can transform specific directory events into a vendor- 
neutral data identification system and then use vendor-neutral transformation 
technologies to transform the neutral data identification into a specific application's 
data format, and vice-versa. 

In one embodiment, the software program includes instructions for receiving 
an event from the distributed directory into a markup language generation system, 
such as an extensible markup language ("XML") generator. The XML generator 
converts the event into XML data and provides the XML data to a transformation 
system, such as an extensible transformation language ("XSLT") processor and/or a 
rule processor (generally "transformation processor"). The transformation processor 
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transforms the XML data to a predetermined format. The format can be dictated by 
a transformation profile, such as a stylesheet and/or one or more rules provided to 
the transformation processor, the transformation profile being responsive to 
requirements of the computer application. The transformed data is then provided to 
the application for the application to use in a conventional manner. 

In some embodiments, the transformed data is transmitted to the application 
through an application shim. Some applications are able to accept input data streams 
while others are not. For applications in this latter group, the application shim may 
intercept the transformed data and provide it to the application by using a native 
application program interface for the application. In this way, if the application does 
not receive XML data, or some other interface necessity exists, the application shim 
can appropriately accommodate the application. 

In some embodiments, the transformation processor can receive updates to the 
transformation profile. These updates, along with any changes to the application 
shim (if necessary), can accommodate any changes in either the distributed directory 
and/or the application. In this way, changes and/or updates to the distributed 
directory or the application can be accommodated in a separate, relatively simple 
manner. 

The summary above discusses events going from the distributed directory to 
the application. However, the present invention also facilitates events going in the 
opposite direction. In one embodiment, a software program includes instructions for 
receiving an event from the application. A markup language generation system, such 
as an XML generator, converts the event into XML data and provides it to a 
transformation processor. The transformation processor transforms the XML data to 
a predetermined format required by the distributed directory. The transformed data 
is then provided to the distributed directory. 

In some embodiments, the transformation processor going this opposite 
direction is the same as the previously mentioned transformation processor. To 
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accommodate the different format requirements of the application and the 
distributed network, different transformation profiles can be used. 

An advantage of the present invention is that it leverages existing text 
transformation technology to provide a general purpose data transformation. 

Another advantage of the present invention is that a new or modified 
application needs simply to write a new application shim (if necessary) and provide 
the appropriate transformation profile. This provides easy integration between 
various applications. 

These and other advantages can be readily seen by further examination of the 
attached figures and the following description. 

Brief Description of the Figures 

Fig. 1 illustrates a simplified computer system including two computers and a 
network, the system being used for implementing one embodiment of the present 
invention. 

Fig. 2 is a diagram of an exemplary distributed directory system used in the 
computer system of Fig. 1. 

Fig. 3 is a functional description of the computer system of Fig, 1 and the 
distributed directory system of Fig. 2. The functional description of Fig. 3 also 
illustrates a routine, such as can be implemented by a software program, for 
implementing one embodiment of the present invention. 

Description of Embodiments 

The present invention provides a unique system and method that invites 
integration between one or more applications and directories without requiring 
significant changes to the applications. It is understood that the following disclosure 
provides many different embodiments, or examples, for implementing different 
features. Techniques and requirements that are only specific to certain embodiments 
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should not be imported into other embodiments. Also, specific examples of networks, 
components, and formats are described below to simplify the present disclosure. 
These are, of course, merely examples and are not intended to limit the invention 
from that described in the claims. 

Referring now to Fig. 1, two similar computer systems, designated 10a and 
10b, are illustrated as a representative example of an operating environment for the 
present invention. Each computer 10a, 10b includes a central processing unit ("cpu") 
12a, 12b, a memory unit 14a, 14b, an input/output ("I/O") device 16a, 16b, and a 
network interface 18a, 18b, respectively. The components 12a, 14a, 16a, and 18a are 
interconnected by a bus system 20a, and the components 12b, 14b, 16b, and 18b are 
interconnected by a bus system 20b. It is understood that each of the listed 
components may actually represent several different components. For example, the 
cpu 12a may actually represent a multi-processor or a distributed processing system; 
the memory unit 14b may include different levels of cache memory, main memory, 
hard disks, and remote storage locations; and the I/O device 16a may include 
monitors, keyboards, and the like. 

The computers 10a, 10b are also commonly connected to a network 30. The 
network 30 may be representative of several networks, such as a local area network, a 
company wide intranet, and/or the internet. Because the computers 10a, 10b are 
connected to the network 30, certain components may, at times, be shared between 
the computers. Therefore, a wide range of flexibility is anticipated in the 
configurations of the computers. Furthermore, it is understood that, in many 
implementations, the computers 10a, 10b may be configured differently from each 
other, may have different components, and/or one computer may act as a server to 
the other computer. 

The present invention facilitates many different operational scenarios of the 
computers 10a, 10b and the network 30. Single server environments and multi- 
server environments, as well as distributed and non-distributed environments, may 
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benefit from the present invention. A distributed, multi-server environment will be 
discussed below to provide just one example of how the present invention operates. 

Referring now to Fig. 2, the computers 10a, 10b and the network 30 are used 
to provide a hierarchical distributed directory system 50. Software running on one or 
more of the computers 10a, 10b provide the directory service, while applications 
running on these computers (or other computers) utilize the directory service. The 
software may be stored on a recordable medium, such as one or both of the memory 
units 14a, 14b, the network 30, or other medium. 

For the sake of example, the directory 50 is a NDS having a logical 
"tree-structure" view of all resources on the network. As a result, the computers 10a, 
10b can access the resources without knowing where the resources are physically 
located (be it computer 10a, computer 10b, the network 30, or some other entity). 
For the sake of example, the directory 50 uses an online directory service protocol 
called LDAP, or Lightweight Directory Access Protocol. The directory includes one or 
more entries, each of which is a collection of attributes with a unique identifier. 

In the present example, the directory 50 is broken into exclusive, non- 
overlapping "containers." A top level container A is connected to different lower 
containers 1, 2, 3, which are then connected to even lower containers a, b, c, etc. In 
furtherance of the present example, the top level container A may represent the 
overall directory structure for a large company; the containers 1, 2, 3 represent 
various cities that the company is located; and the lowest containers a, b, c represent 
different entities of the company, e.g., container a is for sales, container b is for 
marketing, and container c is for engineering. By combining the container names for 
more definite reference, sales la, 2a, 3a is in every city, marketing lb, 3b is in two 
cities, and engineering lc is only in one city. 

One or more contiguous containers can be grouped into a single partition. A 
partition is a logical construct defined by software. Although a partition may be 
responsive to physical constraints (e.g., specific portions of a computer hard drive), it 
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is not limited to a single physical location. In the present example, container A is in a 
partition 52; containers 1 and la are in a partition 54; container lb is in a partition 
56; containers lc is in a partition 58; containers 2 and 2a are in a partition 60; and 
containers 3, 3a, and 3b are in a partition 62. 
5 A computer, such as the computer 10a, can be configured as a server for 

storing one or more partitions and/or having a replica of one or more partitions. 
Replication synchronizes the distributed databases by routinely copying specific 
partition(s) to other servers in the network. Although replicas may be stored in one 
or more servers, any changes to data in a replica will replicate to the other servers 
1 0 storing the same data. 

An application must be aware of the directory's structure, including any recent 
% changes, upgrades, modifications, and so forth. Many applications are not created to 
4= access the directory structure (e.g., the application may not have been rewritten to 

0 utilize directory data access methods), and instead create a partial duplicate of this 
Tt5 structure in their own directory-like data store. Because existing applications may 

y s not be rewritten (due to technical, financial, or other restraints) to directly access the 

U directory, portions of the directory will be fractured among a number of applications 

rU 

m or data repositories. 

1 :a : 
as n 

1 ]f Referring now to Fig. 3, instead of forcing the applications to access the 

directory, the present invention brings the directory to the application. Fig. 3 
provides a functional description of the computers 10a, 10b (Fig. 1) and the directory 
50 (Fig. 2). Since the actual number and the physical arrangement of the computers, 
directories, and the associated applications is inconsequential, the functional 
description of Fig. 3 facilitates a broader understanding of the invention. 

25 In continuance of the present example, a NDS server 100 interfaces with an 

application 102 residing in a system 104. Located between the server 100 and the 
system 104 is an application-integration driver infrastructure (designated generally 
"driver infrastructure") 106. It is understood that the NDS server 100, the driver 
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infrastructure 106, and the system 104 may physically reside on one or more different 
computers. 

In the present example, the driver infrastructure 106 is responsible for 
converting NDS replication events to XML (extensible markup language). XML is a 
common, flexible set of codes for indicating type, purpose, or structure of text in an 
application or directory, but is not specific to the application, directory, or even the 
specific vendor of the application or directory (i.e., it is vendor neutral). The driver 
infrastructure 106 also uses XSLT (Extensible Stylesheet Language Transformations) 
for defining actions that should be applied to the directory information XML to 
transform the directory information into an application native format. One example 
of directory information XML is Novell's DirXML, which is a technique that allows a 
user to create an application view of the information in the directory and then 
replicate that information via XML and an XSLT processor. 

XSLT describes how the XML text is to be transformed into different XML text 
according to a formatting vocabulary. An extensible stylesheet language (XSL) 
defines a style, to be used by the XSLT, for specifying how to transform the XML 
text. XSL has two parts: a language for transforming trees, and a vocabulary of 
formatting objects. The application of XSL has heretofore been used only with 
publishing systems. The present invention applies XSL to directory integration for 
synchronizing multiple data repositories in a general fashion. The XML text can also 
be transformed by one or more rules and other transformation techniques. XML and 
XSL are just one example of generic data description, text conversion and 
transformation technology tools that can be used to implement the present invention. 

The NDS server 100 includes an event handler 110, a driver interface 112, and 
a replica 114. The replica 114 represents at least a portion of the directory 50 (Fig. 2) 
that is stored in the NDS server 100. When a change is made to specific information 
(e.g., a phone number is changed somewhere in the directory 50), that change is 
replicated to the virtual replica 114. The event handler 110 is notified of the change 
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and causes an event. In the present example, the event handler 110 receives filtered 
NDS events via an NDS Event system (not shown) and hands the events off to the 
driver interface 112. The event handler also checks for local transaction events and 
discards any events that should not be provided to the driver interface. The driver 
interface 112 picks up that event, validates the event (e.g., makes sure it is something 
to be handled), and then hands it off to the driver infrastructure 106. 

The driver infrastructure 106 performs a routine to transfer the event to the 
application 102. At step 120, the event (formatted as NDS data) is provided to an 
XML generator 122, which converts the NDS data into XML. In continuance of the 
present example, an NDS event such as the change to the phone number is converted 
into NDS formatted XML. 

At step 124, the XML data is provided to a transformation processor 126, 
which has a transformation profile that tells it how to transform the received 
information. The transformation profile may include a stylesheet and/or one or more 
rules. For example, the stylesheet may define a policy for the subset of NDS 
information that will be propagated to the application, and a data map for how a 
universal schema (e.g., NDS) is translated into an application specific schema. The 
transformation processor 126, which in this example includes an XSLT processor for 
utilizing the stylesheet, then transforms the format of the XML data to one 
appropriate for the application 102 (i.e., application data format). This application 
data format may be specific to the particular application 102, or may be another XML 
format. 

For another example, one or more rules may be provided to the transformation 
processor 126 instead of, or along with the stylesheet. In this example, the 
transformation includes a rules processor to transform the format of the XML data to 
one appropriate for the application 102. In the present embodiment, the rules apply 
to XML, such as a schema mapping rule and or a matching rule. Formatting using 
rules such as these is often better suited than using XSL. It is understood that the 
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transformation processor 126 may utilize an XSLT processor, a rules processor, both, 
or neither. 

At step 128, execution returns to the XML generator 122 and at step 130, 
proceeds to an XSLT transmitter 132. Alternatively, execution may proceed directly 
5 from the XSLT processor 126 to the XSLT transmitter 132 at step 134. At step 136, 
the XSLT transmitter 132 passes the processed data to an application shim 138 
located on the system 104. The processed data can be XSL, XML, LDIF. (LDAP Data 
Interchange Format), or any appropriate format. 

The application shim 138 is a routine that bridges the gap between the driver 
10 infrastructure 106 and the application 102 by calling the application's APIs. In some 
embodiments where the application 102 already receives XML format, the application 
'% shim 138 may be unnecessary. Consider for example that the application 102 is a 
fi Netscape directory which has an API called LDAP modify, as provided by Netscape 
O Comm. Corp. of Mountain View, CA. The LDAP modify API is capable of receiving 

JB5J5. 

J5 and transmitting data in DIF. In this example, the XSLT processor 126 creates an 
p DIF. data file, the XSLT transmitter 132 provides the file to the application shim 138, 
f=* the application shim calls the LDAP modify API, and the LDAP modify API imports 
fij the DIF. data into the Netscape directory 102. In this way, the application shim 138 
l l* is totally dependent on the application 102. 

£D The driver infrastructure 106 works equally well in the opposite direction - 

from the application 102 to the NDS server 100. The application shim 138 must be 
aware of an event occurring in the application 102. This can happen by various 
methods, such as interrupts, polling, and so forth. If required, the application shim 
138 can convert changes in the application's native directory into an application 

25 native XML format, and then submit that XML data stream to the driver 
infrastructure 106. 

At step 140, the event (formatted as application data) is provided to an XML 
generator 142, which converts the application data into XML. At step 144, the XML 
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data is provided to the transformation processor 126, which has a profile that tells it 
how to transform the received information. A separate transformation profile may be 
required to do transformations in this opposite direction, as compared to the profile 
for data going from the replica 114 to the application 102. 

The XSLT processor 126 then changes the format of the XML data to one 
appropriate for the NDS server 100 (e.g., NDS data format). This NDS data format 
may be specific to the NDS server, or may be another XML format. At step 146, 
execution returns to the XML generator 142 and at step 148, proceeds to an XSLT 
receiver 150. Alternatively, execution may proceed directly from the XSLT processor 
126 to the XSLT transmitter 150 at step 152. At step 154, the XSLT receiver 150 
calls the APIs for the NDS server 100 and passes the processed data as NCP 
(Netware core protocol) requests to the NDS replica 114 located on the NDS server. 
The replica 114 then propagates the changes to any other replicas (if any exist) as 
replication events. 

In the present example, the driver infrastructure 106 resides on the NDS 
server 100 (e.g., computer 10a of Fig. 1) and the application 102 resides on the system 
104 (e.g., computer 10b of Fig. 1). The application shim 138 can reside on the NDS 
server 100, on the system 104, some other remote system, or split there between. If 
the application shim 138 is on a system other than the system 104, it can take 
advantage of remote APIs (like LDAP modify). 

In summary, several different processing structures are disclosed, some or all 
of which may be utilized to implement the present invention. In the examples 
discussed above, the driver infrastructure is responsible for converting replication 
events to a set of codes for indicating type, purpose, or structure for application 
consumption. The driver infrastructure also receives a set of codes from the 
application and provides it to the server. 

A server/driver infrastructure interface is responsible for the receipt of filtered 
events and converting them to the appropriate data format. It then hands the 
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formatted data to a transformation processor. In the above example, this interface 
includes the XML generator 122, which converts NDS events into NDS formatted 
XML, and the XML receiver 150, which converts NDS formatted XML events into 
NCP requests to the NDS replicas 114. 

A system/driver infrastructure interface is responsible for the transmission 
and receipt of transformed events to the application 102. If the application has an 
event interface and/or is able to accept the events directly, then this component is not 
required. Otherwise, as in the above examples, the application shim 138 will accept 
application native data stream from the driver infrastructure 106 and process it into 
application native APIs. It also will convert changes in the application native 
directory into an application native XML format, for submission to the driver 
infrastructure 106. 

An advantage of the present invention is that it leverages a technology like 
XML to provide a general purpose transformation. 

Another advantage of the present invention is that a new or modified 
application needs simply to write a new application shim (if necessary) and provide 
the appropriate transformation profile(s). This provides easy integration between 
various applications without incurring the prohibitive costs of rewriting the 
application. 

Another advantage of the present invention is that by storing the policy and 
data mapping information within NDS by using a structure like the transformation 
processor 126, application integration is simplified. 

It is further understood that other modifications, changes and substitutions 
are intended in the foregoing disclosure and in some instances some features of the 
disclosure will be employed without corresponding use of other features. Accordingly, 
it is appropriate that the appended claims be construed broadly and in a manner 
consistent with the scope of the disclosure. 
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We Claim: 



1 1. A method for interfacing a directory to an application in a computing system, 

2 the method comprising the steps of: 

3 providing a transformation profile for defining a predetermined format for use 

4 by the application; 

5 detecting an event in the directory; 

6 transforming the event to the predetermined format by using a transformation 

7 tool and the transformation profile; and 

8 providing the transformed event to the application; 

9 whereby the application becomes aware of the event by having the event 
JjJO provided to the application in a transformed state. 

01 2. The method of claim 1 further comprising the step of: 

iz2 converting the event to a generic data description before transforming the 

y ^3 event. 

3 

IFi s 

ry 1 3. The method of claim 1 further comprising the step of: 

* s lt2 providing an application shim for the application to receive the transformed 

event and provide the event to the application by using a native application program 

4 interface for the application. 

1 4. The method of claim 3 further comprising the step of: 

2 updating the application shim and the transformation profile responsive to 

3 changes in the application. 

1 5. The method of claim 1 wherein the transformation profile includes a 

2 stylesheet. 
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6. The method of claim 1 wherein the transformation profile is stored in the 
directory. 

7. A software program for facilitating the use of a distributed directory running 
in a computer network, the program comprising being stored on a recordable medium 
and including instructions for: 

receiving an event from the distributed directory into an XML generator; 
converting the event into XML data; 

transforming the XML data to a first predetermined format by a 
transformation processor, the first predetermined format being responsive to an 
application running in the computer network; and 

transmitting the transformed data to the application. 

8. The software program of claim 7 wherein the transformation processor 
includes an XSLT processor, the program further comprising instructions for: 

providing a stylesheet to the XSLT processor, the stylesheet including 
formatting instructions for transforming XML data to the first predetermined 
format. 

9. The software program of claim 8 further comprising instructions for: 
receiving updates to the stylesheet responsive to any changes in either the 

distributed directory or the application. 

10. The software program of claim 7 wherein the transformed data is transmitted 
to the application through an application shim to provide the transformed data to the 
application by using a native application program interface for the application. 
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11. The software program of claim 7 further comprising instructions for: 
detecting the event through notification from an event handler of the 

distributed directory. 

12. The software program of claim 7 further comprising instructions for: 
receiving a second event from the application; 

converting the second event into XML data; 

transforming the XML data to a second predetermined format by the 
transformation processor, the second predetermined format being responsive to the 
distributed directory; and 

transmitting the data transformed according to the second predetermined 
format to the distributed directory. 

13. The software program of claim 12 wherein the transformation processor 
includes an XSLT processor, the program further comprising instructions for: 

providing a first stylesheet to the XSLT processor, the first stylesheet 
including formatting instructions for transforming XML data to the first 
predetermined format: 

providing a second stylesheet to the XSLT processor, the second stylesheet 
including formatting instructions for transforming XML data to the second 
predetermined format. 

14. The software program of claim 12 wherein the transformed data is transmitted 
from the application through an application shim. 
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15. A software program for facilitating the use of a distributed directory running 
in a computer network, the program comprising instructions for: 

receiving an event from the application; 

transforming the event to a predetermined format by a transformation 
processor, the predetermined format being responsive to the distributed directory; 
and 

transmitting the transformed event to the distributed directory. 

16. The software program of claim 15 further comprising instructions for: 
converting the event into markup language data prior to transforming the 

event. 

17. The software program of claim 15 further comprising instructions for: 
providing a transformation profile to the transformation processor, the 

transformation profile including formatting instructions for transforming the 
markup language data to the predetermined format. 
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1 18. A distributed computer system comprising: 

2 a first processor connected to a network for executing computer code; 

3 a second processor connected to the network for executing computer code; 

4 a first memory connected to the first processor; 

5 a second memory connected to the second processor; 

6 a distributed directory, a portion of which being stored in the first memory; 

7 an application, a portion of which being stored in the second memory; 

8 a transformation profile for defining a predetermined format for use by the 

9 application; 

10 software for detecting an event in the distributed directory; 

1 1 software for transforming the event to the predetermined format by using a 
%2 generic transformation tool and the transformation profile; and 

Jt3 software for providing the transformed event to the application; 

□4 whereby the application becomes aware of the event by having the event 

%5 provided to the application in a transformed state. 

ui 

3 

M*l 19. The system of claim 18 further comprising: 

HP 

fj }2 software for converting the event to a generic data description before 

3 ]: 3 transforming the event. 

1 20. The system of claim 18 further comprising: 

2 an application shim for the application to receive the transformed event and 

3 provide the event to the application by using a native application program interface 

4 for the application. 

1 21. The system of claim 18 further comprising: 

2 a second transformation profile for defining a second predetermined format for 

3 use by the distributed directory; 
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1 software for transforming an application event to the second predetermined 

2 format by using the generic transformation tool and the second transformation 

3 profile; and 

4 software for providing the transformed application event to the distributed 

5 directory; 

6 whereby the distributed directory becomes aware of the application event by 

7 having the application event provided to the distributed directory in a transformed 

8 state. 

1 22. The system of claim 21 wherein the generic transformation tool utilizes a 

2 markup language and the software for transforming the event and the application 
event utilizes a transformation processor. 
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COMPUTER DIRECTORY SYSTEM HAVING AN 
APPLICATION INTEGRATION DRIVER INFRASTRUCTURE 



Abstract 

An application integration driver infrastructure for facilitating the use of a 
distributed directory running in a computer network is provided. The infrastructure 
can transform specific directory events into a vendor-neutral data identification 
system and then use vendor-neutral transformation technologies to transform the 
neutral data identification into a specific application's data format, and vice-versa. 
The infrastructure receives an event from the distributed directory into a markup 
language generation system, such as an extensible markup language ("XML") 
generator. The XML generator converts the event into XML data and provides the 
XML data to a transformation processing system, such as an extensible 
transformation language ("XSLT") processor. The XSLT processor transforms the 
XML data to a predetermined format. The format can be dictated by a stylesheet 
provided to the XSLT processor, the stylesheet being responsive to requirements of a 
computer application. The transformed data is then provided to the application for 
the application to use in a conventional manner. The application may use an 
application shim to convert the transformed data into a native application program 
interface ("API") for the application. 
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as Application Serial No. . 
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such willful false statements may jeopardize the validity of the application or any patent 
issued thereon. 
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